Gravity Forms v1.9 Now Available Via Automatic Update

Gravity Forms v1.9 is now available via automatic update for existing users.

As we mentioned in the Gravity Forms v1.9 release announcement, we chose to delay making v1.9 available via automatic update so that we could include any post-launch fixes before users updated existing installs.

This is a major feature release that includes a variety of highly anticipated new features. For a complete rundown of what is new in Gravity Forms v1.9, check out the release announcement.

Share This
10 Responses to "Gravity Forms v1.9 Now Available Via Automatic Update"
  1. artpeople says:

    the list option in gravity form no longer work properly. before update worked fine, after up date the little + button no longer appears next to the list box when form is published.

    • Carl Hancock says:

      @artpeople I'm unable to reproduce an issue with the List Field. The List Field is working as expected in my tests and the plus/minus icons to add/remove items to the list is displaying as designed. See this screenshot: http://d.pr/i/xlEA

      The first thing I would suggest trying is clearing your browser cache. Your browser could have old data cached and could be why you do not see the icons. If clearing your browser cache and reloading doesn't work submit a support ticket on our site and our support team will assist you.

  2. bitbia says:

    Hi there! 🙂

    What about 1.9.1.2? I see nothing about it in the changelog.

    • Carl Hancock says:

      @bitbia The version pushed out via automatic update was v1.9.1.2 because we originally packaged up v1.9.1 for release on Tuesday but delayed releasing it until Wednesday. When Wednesday rolled around we were able to include 2 additional fixes so the version that was deployed was v1.9.1.2. There is a complete breakdown in the changelog.txt file within the plugin zip file that you can download from the support site.

  3. We updated the list images in this release. Both are now scalable vector graphics (SVG) files for better rendering in HD/Retina displays. That said, I would agree that refreshing the browser cache would be the first step in trying to solve your issue.

  4. websherpa says:

    This version seems to have upset how the Name field is displayed in all our layouts. I have posted a Support Request, but am wondering if it was update related? (I too am having issues now with list displays.)

    • Carl Hancock says:

      @websherpa Support will be the best way to handle any issues related to the update. It is possible custom code may need to be updated. This was the primary reason v1.9 was available as a beta release for such a long time, to give users an opportunity to test custom code they may have implemented for compatibility and to give them time to update the code.

      As for remove of the simple name field, it still exists for backwards compatibility purposes. Existing forms that utilize it shouldn't be impacted. For new forms if you need a simple name field you can use the standard single line text input field. I'm not sure what specifically couldn't be done with using a standard single input vs. the old simple name format. They were both simply standard text input fields. The only difference being how they were added to a form in the Form Editor.

  5. bitbia says:

    Hi @Carl. Ok, great! Thanks for your quick reply! 🙂

  6. websherpa says:

    To be honest it is quite likely that I am having CSS and GF Add-on plugin conflicts. My only concern for the Name field is that existing Add-ons that use that field (like Campaign Monitor and User Registration) and those custom aspects where we pre-fill those fields from existing User Meta data still function ok (I have not tested yet - I am just worried now). I guess it's that GF was so stable with our existing code for so long, that for me this was unexpected. Thank you for the reply.

    • Carl Hancock says:

      @websherpa The simple name format wasn't fully removed. Only the UI to add a new field using the format was removed. The underlying code still exists. It was designed to be backwards compatible so that existing forms using this deprecated functionality would continue to work just fine, including when integrating with an Add-On.

      The reason for the change is a single input for a full name is terrible from a data portability and integration standpoint. When you integrate with 3rd parties (payment processors, etc.) via Add-Ons, etc. they typically want a name in chunks (first name, last name, etc.) and not as a single string. While you can take a single string and attempt to break it up into first name and last name using code it won't be accurate because of the large variation in people's names. It then becomes even more problematic if they enter their middle name or middle initial within a name field using a single input when you are trying to break it up dynamically using code from a single stream.

      By capturing the name using multiple inputs it makes the data much more portable and eliminates issues with 3rd party integrations and add-ons related to name formatting.

      Combined with the enhancements we've made to the Name Field and the future enhancements we plan on making to the Name Field eliminating the concept of name formats makes much more sense. The other side to the change was the fact that the Name Field when configured using the simple name format was nothing more than the Single Input Field with a field label of "Name". There was no difference between the two other than how it's added to the form.

Leave a Reply